\\M1NGR25;\F1

\CCOLLECTION OF RANDOM COMMENTS, COMPLAINTS, AND CRAP ABOUT CIS280

\J
1. The worst  thing that was said  on the course reviews:  "He should
have taught the compiler course." 

Well, I think compiler courses are too narrow a study of the problems
of computer  languages. In  the  first place  a one  semester  course
typically  consists   of  85%   syntax  analysis  and   15%  semantic
considerations.  Whereas the emphasis should be completely reversed. 
The problems of syntax are important but they tend to  be only a very
small portion  of the problems  of translator writing.   Their saving
grace seems to be  that they are  a nice comfortable,  mathematically
well-defined niche, well away from the cold.  If you believe that the
reason  for studying  this kind  of  compiler course  is to  become a
"parser-writer", then lucky you. I  happen to feel that the  problems
in language  implementation are  not "write  a super-fast  parser for
XXX",  but "what the ______ should XXX  be?" You don't understand the
problems of language design by studying syntax analysis. 

This harangue  is really  directed to a  discussion of  just what  a
University education in  (software) Computer Science should be. First
point: the  distinction  between  software  and  hardware  should  be
discouraged. In  is  not reasonable  to expect  hardware people  with
limited  software background to design  machines which are reasonable
devices to program. Similarly,  software types cannot be ignorant  of
hardware  considerations if  they expect  to  have an  impact on  the
design  of their machines. (Indeed the  problems are compounded in an
Interdisciplinary program like the  current one!) I believe  that the
current  University  exposure   to  Computer  Science  should  be  as
traumatic as possible.   If you  want to be  assured of the  "eternal
truth"  pick another  major or  go  to Condie  College  and become  a
technician.    The current  state  of  C.S.   just  doesn't  support a
"comfortable" presentation.   The field is  just beginning to  become
respectable, most of the ideas are really quite close to the surface. 
But  to teach  C.S. courses  with the  implied confidence  that, say,
mathematics courses demand, would be a disservice.  What was suitable
fare  for graduate  seminars  3 years  ago,  is now  being taught  to
undergraduates. The field is changing very rapidly, both  technically
and  intellectually.   It  should  therefore  be the  position  of  a
University  program to  try to  point out  those bright  lights which
might perhaps endure, and to show up any and all fallacies  which are
being currently  touted as the "final  truth". Thus when I  said that
you should become skeptics as a result of this course, I meant it. 

This  rapid change in C.S. points  up another difficult in department
set-ups: namely the difficulty of "staying up". The lead time on book
publishing is  3-5 years.  The  lead-time on journal  articles is 1-2
years. Most research papers float  in the "underground" for a  couple
of years before they  make it even to a  journal.  So if you  want to
stay current you  need a tap into the subconscious. This again points
out a difference between an established traditional subject  and C.S.
Graduate  math programs  have sufficient  depth and  rich history  to
support lots  and lots of well-established courses. C.S. just doesn't
have the requisite depth yet;  it will, but it is still  really quite
shallow.   Granted, you can take  last years math course  and add two
weeks of programming and call it a C.S. course, but that's not  C.S. 
any more than  a horse with seat belts  is a car (or  cdr). Similarly
E.E.   hardware courses with additional study  of the current machine
technology aren't satisfactory. (Notice  its much easier to say  what
isn't than what is.)

2. Best thing said. "It wasn't practical." 

Well, when you take graduate E.E. courses they don't teach you how to
change  light bulbs; when  you take graduate math  courses they don't
teach  you  how to  balance  your  checkbook.  A  similar  degree  of
detachment   and  sophistication   is  demanded   in   most  graduate
departments. In particular it should  be a primary responsibility  of
C.S. departments to attempt to show how  things should be done rather
than  show how  things  are currently  being done.  Granted  that the
typical  data structures  course  is  a  tour  through  the  maze  of
techniques and trickery  for representation of data.  I however don't
believe  that this is  a beneficial approach.   First it implies  that
all is right with  the world and we will  simply pass on to  you poor
unfortunates all that you need. Second it instutionalizes a premature
departmentalization of the field(wow, that does sound GOOD!!!).  That
is we can  separate out, data structures from  compiler construction,
from systems  programming, from language design, and from programming
style or philosophy, and  study them separately. Indeed according  to
most college  catalogs, we can  study data structuring BEFORE  all of
these  other topics. Bull  shit.  The techniques  of data structuring
were natural outgrowths of complex programming; taken in that context
they  are really quite  simple.   Taken out  of context,  they become
unnecessarily arcane tricks,  and students  exposed to  them in  this
manner either don't see how they should be applied: either they don't
see  at all,  or want  to represent  everything as  a linked  list or
threaded binary tree. 


3. I'm glad you asked  that question: "What happened to our  computer
time?"

Yes you should have had exposure  to a machine to run LISP programs. 
A  major difficulty is that  LISP really is  an on-line language. The
construction  debugging  and   running  of  LISP  programs   is  most
comfortably  done at a  console.   Particularly when  the language  is
being learned. Since  the programs  are expressed to  the machine  in
their s-expression representation, the syntax is vile! If you have to
(bleagh) punch cards you are almost guaranteed to make errors. If you
must wait for output  the experience becomes incredibly  frustrating.
Since this  was not a  class in LISP  programming, and since  I don't
expect students to do things I wouldn't do, I decided to stay off the
machine. (See 4. below also). Here's another complaint about courses:
Courses like  "Programming in XXX". Programming  languages are tools;
they should be studied as such.  In other departments they should  be
used in an applications course. There we need to show that the traditional
approach to the subject matter can be improved by using a computer.
The student should have access to a terminal so that he may learn the
necessary language, but the programming language should simply
augment the existing material. In  C.S. we should  study languages like  medical
students study cadavers.  (In LISP we study cadadrs... sorry!?!)
Perhaps  if the engineering school offers a
course  in Advanced Crescent Wrench, then  C.S. should feel obligated
to respond with a programming language course, but until then ... 

4. Pace -- "about right: ~75%" 

Bull. This course was done much too fast. In fact if  you look at the
rating on  "class discussion, question handling" and  to some extend,
"clarity of  goals", it  puts the  lie to  "about right".  If we  had
another semester I would start over from page 1, and do it all
over  again.  To  cover the  material correctly would  require a  full
year. But  since there  was only  one semester,  I felt  is was  more
valuable to  do everything through once.  Then you would at  least be
exposed to the material; if you had the interest you can read it over
yourselves; if  you don't  then _____ __  _____ _____.  I would  have
preferred  to spend  much more  class time  answering  questions
and pontificating, but
there just isn't  time. I  would have preferred  to have  programming
projects, and indeed implementation experiments  but there isn't time
in  one  semester.  Implementation  of  languages  requires a  through
understanding of  all aspects  of the  language. That  sophistication
itself requires  at least a  semester. That,  by the way,  is another
objection to the typical compiler course; the requisite depth is either
ignored or presupposed. In either case someone gets short-changed.

However,  on the other  side, the sharp division  in "encouraged your
interest" (indeed in most of the responses!!) leads  me  to believe  
that I  didn't  convince anyone  who
wasn't convinced  before. For you  doubting Thomas's: eat  your heart
out. 

5. Clarity of course goals -- "relatively losing: ~65%"

I believe that. It could stem from two sources: first, the rapid
coverage of the material without appropriate pauses to regroup and
relate the material. 
A more leisurely course could have subdued this. 

However my favorite excuse is that you expected
a nice neat course on technique-ery, and you didn't get it. I think
student, and people in general, want answers rather than lots and
lots of questions.  Of course, there's another alternative: the person
who didn't like any of the course might be right-- it's all a krok.

6. Most puzzling response -- "accessibility to students: ~65% above good"

Incredible!! I was only there 4 hours a week. Perhaps you meant
"irascibility to students"?